建立一個地城的「輪廓」倒不是難事，物理引擎可以幫忙處理很多問題，像「怎麼判斷碰撞到牆壁」。

以之前範例中頻繁使用到的「Wall」這個類別來說，它僅僅只是在畫面上畫條線（依靠程式設計師賦予的起始與終點）完美的執行了擔任「資訊意義」上牆壁的功能，「這裡是否有牆？」，看畫面不準，看這個「Wall」的設定值最準。
很可惜，遊戲需要畫面，牆壁只是一條線的遊戲在這年頭通常是行不通的。

那將「Wall」實際上會呈現的畫面（一片牆）另外設計為一個「WallTexture」，然後將它設計為依附在「Wall」裡面（成為一部分的參數），當「Wall」被建構時，「WallTexture」一定也會被建構，並使用「Wall」的建構參數（起始與終點座標），然後加上自己獨有的設定「牆的高度」，有了這些設定（起始與終點座標和牆的高度），一條線就會變成一面牆。

以上所說都是理所當然的基礎知識。
真正的問題剛要開始。

就圖學來說，材質填充（render）的順序應該是從螢幕的上方開始，至於左右，我想應該沒有差別，一般來說，這都有遊戲引擎代勞判斷順序。

但這裡、我所進行的範例，有個問題就是「它從頭到尾都沒有材質需要進行填充，因為它是Canvas繪圖指令的點線面。」這樣繪製出來的牆壁概念上來說是透明的！
也就是說即使按照「從螢幕的上方開始」這樣的順序去依序繪製牆壁，玩家還是能看到牆壁後面的東西。

所以每次要繪製新的牆壁時，都需要依照牆壁的輪廓去進行「Canvas.clip」（剪裁），將牆壁後面的東西「剪掉」。
這個動作會耗損效能。
而且是很多效能。

改善效能的方式並不多，（這可能是為什麼這種風格的遊戲會完全從市場上消失不再回來的原因。）
最主要就是「預先判斷每一面牆壁將會被遮蔽的範圍，然後完全跳過該範圍內的Canvas繪圖」。
但「判斷」本身又是個吃效能的東西，不只是「預先判斷」這件事，繪製時還要判斷「這塊繪圖是否要被跳過」一樣吃效能，而且演算法的設計....坦白說，我的圖學功力沒那麼高！

還是老老實實做「Canvas.clip」吧！

（晚點！過幾天再補上範例程式碼！）